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Tri de la table de faits et compression des index bitmaps avec 

alignement sur les mots 

Kamel Aouiche^, Daniel Lemire^ et Owen Kaser^ 
Résumé 

Les index bitmaps sont souvent utilisés pour indexer des données multidimensionnelles. Ils 
utilisent principalement l'accès séquentiel aux données, tant à l'écriture qu'à la lecture. Les 
bitmaps peuvent être compressés pour réduire le coût des entrées/sorties tout en minimisant 
l'utilisation du microprocesseur. Les techniques de compression les plus efficaces sont fondées 
sur la compression par plage {run-length encoding) telle que la compression alignée sur les mots. 
CN| Ce mode de compression permet d'effectuer rapidement des opérations logiques (AND, OR) sur 

les bitmaps. Cependant, la compression par plage dépend de l'ordre des faits. Nous proposons 
^ donc d'exploiter le tri de la table de faits afin d'améliorer l'efficacité des index bitmaps. Le tri 

<^ lexicographique et par cîoclc de Gray, ainsi que le tri par bloc, sont évalués. Selon nos résultats 

expérimentaux, un simple tri lexicographique peut produire un index mieux compressé (parfois 
I deux fois plus petit) et qui peut être plusieurs fois plus rapide. Le temps requis par le tri apporte 

un surcoût au temps total d'indexation, mais ce surcoût est amorti par le fait que l'indexation 
d'une table triée est plus rapide. L'ordre des colonnes peut avoir une influence déterminante sur 
l'efficacité du tri lexicographique : il est généralement préférable de placer les colonnes ayant 
plus de valeurs distinctes au début. Le tri par bloc sans fusion est beaucoup moins efficace qu'un 
^ tri complet. De plus, le tri par code de Gray n'est pas supérieur au tri lexicographique dans le 

O cas de la compression alignée sur les mots. 

Mots-clefs : index bitmap, optimisation, compression, codes de Gray 
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On Fact Table Sorting and Word-Aligned Compression for Bitmap Indexes 

Bitmap indexes are frcqucntly used to index multidimensional data. They rely mostly on se- 
çT^ quential input/output. Bitmaps can be compressed to reduce input/output costs and minimize 

ly-^ CPU usage. The most efficient compression techniques are based on run-length encoding (RLE), 

such as Word-Aligned Hybrid (WAH) compression. This type of compression accélérâtes logical 
OO opérations (AND, OR) over the bitmaps. However, run-length encoding is sensitive to the order 

of the facts. Thus, we propose to sort the fact tables. We review lexicographie, Gray-code, and 
^ block-wise sorting. We found that a lexicographie sort improves compression — sometimes gene- 

r '"j rating indexes twice as small — and make indexes several times faster. While sorting takes time, 

rN this is partially offset by the fact that it is faster to index a sorted table. Column order is signifi- 

cant: it is generally préférable to put the columns having more distinct values at the bcginning. 

A block-wise sort is much less efficient than a fuU sort. Moreover, we found that Gray-code 

sorting is not better than lexicographie sorting when using word-aligned compression. 
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1 Introduction 



Table de faits 



Index bitmap 



Les entrepôts de données stockent de grands 
volumes de données : il n'est pas rare de trou- 
ver des entrepôts faisant plus de 100 To [15] et 
parfois même jusqu'à 10 Po [2]. On trouve des 
tables faisant plus d'un billion de faits (lO"*^^) [2]. 
La construction rapide d'index multidimension- 
nels sur de grands volumes est donc indispen- 
sable pour accélérer l'accès aux données. La tech- 
nique des index bitmaps (ou index binaires) est 
l'une des solutions les plus communément utili- 
sées avec l'arbre B et les tables de hachage. 

Sans compression, certains index bitmaps sont 
peu pratiques. Par exemple, l'indexation d'un 
seul attribut comportant 10 millions valeurs et 
100 000 valeurs distinctes nécessiterait un téra- 
octet. Dans le but de réduire la taille des in- 
dex bitmaps et de les rendre plus efficaces, plu- 
sieurs méthodes de compression ont été propo- 
sées. Nous citons la compression par plage [14], 
la compression alignée sur les octets BBC {Byte- 
Aligned Bitmap Compression) [1], et la com- 
pression Lempel-Ziv (LZ77) [4] . Une autre tech- 
nique de compression, plus compétitive que la 
simple compression par plage, est la compres- 
sion alignée sur les mots WAH {Word-Aligned 
Hybrid) [25]. En comparaison avec LZ77 et BBC, 
WAH fournit des index parfois beaucoup plus 
rapides [24]. 

Nous étudions dans ce papier plusieurs mé- 
thodes de tri pour améliorer la compression et 
le temps de calcul des index bitmaps. Le tri, 
comme le montre la Figure 1, peut être appli- 
qué sur les faits ou sur les codes binaires assi- 
gnés aux faits. Nous nous intéressons plus parti- 
culièrement au tri lexicographique et au tri par 
code de Gray. De plus, nous discutons de l'or- 
donnancement des dimensions selon leurs car- 
dinalités afin d'améliorer le coût de stockage et 
de calcul des index bitmaps (voir la Figure 1). 
L'étude réalisée dans ce papier porte particuliè- 
rement sur les tables de faits. Cependant, elle 
valable dans un contexte de table autre qu'une 
table de faits. A notre connaissance, il s'agit de 
la première étude portant sur cette question. 
Jusqu'à présent, seul le tri des faits par code 
de Gray a été proposé [3, 18]. Cependant, ces 
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FiG. 1: Application du tri et de l'ordonnance- 
ment des dimensions pour améliorer les perfor- 
mances des index bitmaps. 

derniers travaux n'ont considéré que le cas d'in- 
dex de petites tailles : le plus volumineux des 
index comporte 2 millions de faits et 900 bit- 
maps. La description des auteurs du tri par code 
de Gray suppose en effet que l'index bitmap soit 
d'abord matérialisé sans compression ; ce qui est 
coûteux en espace de stockage et temps de cal- 
cul. Dans notre cas, nous considérons des di- 
mensions ayant plus de 50 000 bitmaps et des 
tables ayant plus de 100 millions de faits. Nous 
étudions l'effet que le tri préalable des faits a 
sur les temps de création des index et d'interro- 
gation des données. 

2 Index bitmaps 

2.1 Principes de base 

Les entrepôts de données représentent sou- 
vent leurs données sous la forme d'une table de 
faits (Tableau 2a) et des tables de dimensions 
(Tableau 2b). Une table de faits est composée de 
plusieurs colonnes (attributs : clés étrangères et 
mesures) et de plusieurs rangées (faits). Une di- 
mension donnée peut prendre plusieurs valeurs : 
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Tab. 1: Une table de faits, des tables de dimen- 
sions et un index bitmap 



id- Ville id- Véhicule id-Couleur quantité 
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1 

Table de faits 
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id 


Ville 


id 


Véhicule 


id 


Couleur 
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Montréal 
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Voiture 
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Bleue 
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Paris 
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Autobus 
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Rouge 
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Londres 
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Verte 
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Québec 
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Tokyo 
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Lyon 











(b) Tables de dimensions 



100000 


10 


100 


010000 


01 


100 


001000 


10 


010 


000100 


10 


100 


000010 


10 


001 


100000 


01 


100 


000001 


01 


100 



(c) Index bitmap simple 

la dimension « Ville » peut prendre les valeurs 
« Montréal », « Paris », etc. Les tables de faits 
peuvent atteindre des volumes importants, al- 
lant de millions de faits dans le cas de petites 
entreprises, à des milliards de faits ou encore 
plus dans le cas de grandes entreprises. Afin de 
supporter efficacement les requêtes en ligne sur 
de telles tables, des index sont souvent néces- 
saires. 

Le premier exemple d'un index bitmap dans 
un moteur de base de données (MODEL 204) a 
été commercialisé pour l'IBM 370 en 1972 [17]. 
On trouve maintenant les index bitmaps dans 
de nombreux moteurs de base de données, dont 
les bases de données Oracle. Le principal avan- 
tage de ce mode d'indexation est de favoriser 
l'accès séquentiel aux disques tant à l'écriture 



qu'à la lecture des données [10]. 

Le principe de base d'un index bitmap est de 
représenter les faits de telle manière à ce que 
les requêtes se traduisent par de simples opéra- 
tions logiques (AND, OR). Pour chaque valeur 
V d'un attribut a d'une dimension, un index bit- 
map est composé d'un tableau de booléens (ou 
bitmap) ayant autant de bits que de faits et 
dont les positions des bits mis à 1 correspondent 
aux faits pouvant être joints avec cet attribut. 
Le Tableau 2c montre un exemple d'un index 
bitmap. Par exemple, le tableau de booléens 
1000010 correspond au prédicat « Ville = Mont- 
réal » ; qui n'est vrai que pour le premier et 
le sixième faits. De la même manière, le prédi- 
cat « Véhicule = Autobus » donne le tableau 
de booléens 0100011. A titre d'illustration, les 
résultats de la requête « Véhicule = Autobus 
AND Ville = Montréal » sont calcules en réa- 
lisant le AND logique sur les deux tableaux de 
booléens précédents. 

Les index bitmaps sont rapides parce qu'au 
lieu de lire toutes les valeurs possibles d'un at- 
tribut donné, on peut ne lire qu'aussi peu qu'un 
bit par fait et par attribut, ou même moins 
si l'on exploite des techniques de compression. 
Par ailleurs, un microprocesseur peut calculer 
32 ou 64 opérations logiques sur un bitmap en 
une seule instruction. Le regroupement des bits 
d'un bitmap par paquets de 32 ou de 64 bits ne 
peut donc qu'améliorer grandement l'efficacité 
des index bitmaps. 

Alors qu'on considère parfois que les index 
bitmaps sont surtout appropriés pour les attri- 
buts de petite cardinalité, comme le sexe ou le 
statut marital, Wu et al. ont montré qu'ils sont 
également efficaces lorsque les cardinalités des 
données sont très élevées [20,25]. Par ailleurs, 
les index bitmap permettent d'indexer plusieurs 
dimensions sans mal, alors que les performances 
des index multidimensionnels en arbre tels que 
les arbres R, se dégradent rapidement lorsque le 
nombre de dimensions augmente [23]. 

2.2 Encodage des index bitmaps 

Il est possible de réduire le nombre de ta- 
bleaux de booléens, donc de bitmaps, lors de 
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l'indexation de données de forte cardinalité. Un 

index bitmap simple d'un seul attribut ne com- 
porte qu'une seule valeur vraie par fait (« Mont- 
réal » devient 100000) et un bitmap par valeur 
distincte de l'attribut. Observons qu'étant don- 
nés L bitmaps, il existe (2) = L{L — l)/2 paires 
de bitmaps. En représentant les valeurs de la 
colonne non plus par la position de la valeur 
vraie, mais plutôt par la position de deux va- 
leurs vraies (« Montréal » devient 1100), on 
peut utiliser beaucoup moins de bitmaps (voir 
le Tableau 2) : {y/SN + 1 + l)/2 bitmaps suf- 
fisent pour représenter N valeurs distinctes. Par 
exemple, seuls 2 000 bitmaps sont nécessaires 
pour représenter 2 millions de valeurs distinctes. 

De manière plus générale, l'encodage k-oî-N 
permet de n'utiliser que L bitmaps pour repré- 
senter (^) valeurs distinctes. En contrepartie, 
au lieu de charger un seul bitmap correspon- 
dant à une valeur d'attribut impliquée dans une 
requête, il faut désormais en charger k bits, et 
effectuer une opération logique AND sur l'en- 
semble des données. 

Lorsqu'il existe une hiérarchie sur une dimen- 
sion, on peut utiliser une variante de l'encodage 
k-oî-N qui soit particulièrement appropriée : on 
utilise les premiers hi bitmaps pour le premier 
niveau de la hiérarchie, les /12 bitmaps suivants 
pour la deuxième et ainsi de suite. Par exemple, 
si les 3 premiers bitmaps sont dédiés au premier 
niveau de la hiérarchie (Canada, France, Bel- 
gique), et que les 5 bitmaps suivants sont utili- 
sés pour distinguer l'une des 5 villes dans cha- 
cun des pays, « Paris » pourrait avoir le code 
10010000 alors que « Montréal » pourrait avoir 
le code 01010000. Il s'agit d'une forme de dé- 
normalisation [11] qui permet d'éviter à avoir 
un index distinct sur les données après un roll- 
up sur une dimension. 

On peut aussi regrouper les valeurs des attri- 
buts dans des lots [12,19,21] lorsque leur nombre 
est très important. Par exemple, au lieu d'uti- 
liser un bitmap pour chaque rue de Paris, on 
peut utiliser un bitmap par quartier. Il existe 
des encodages pour supporter les requêtes par 
plage lorsque la cardinalité des attributs est im- 
portante [5]. 



Tab. 2: Comparaison entre l'encodage l-of-A'^ 
et l'encodage 2-of-N 
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1100 


010000 


1010 


001000 


1001 


000100 


0110 


000010 


0101 


100000 


1100 


000001 


0011 


(a) 1-of-iV (b) 2-of-iV 



Lorsqu'on réduit le nombre de bitmaps, on 
augmente aussi la densité de l'index, c'est-à-dire 
le ratio des valeurs vraies par rapport aux va- 
leurs fausses. Si l'encodage 2-oî-N génère tou- 
jours un index bitmap non compressé beaucoup 
plus petit que l'encodage 1-of-iV, la même chose 
n'est pas nécessairement vraie si l'on compresse 
l'index. 

Lorsqu'on souhaite indexer une table à l'aide 
de l'encodage k-oî-N pour A; > 1, il arrive qu'on 
puisse générer un index particulièrement ineffi- 
cace sur les colonnes ayant peu de valeurs dis- 
tinctes. Par exemple, si seulement 5 valeurs dis- 
tinctes sont observées, un encodage simple (1- 
of-5) n'utilisera que 5 bitmaps alors qu'un en- 
codage 2-of-A?" exigera 4 bitmaps. Il est certain 
qu'un encodage 2-of-4 sera moins efficace qu'un 
encodage l-of-5. Nous appliquons donc l'heu- 
ristique suivante pour nos tests. Toute colonne 
ayant 5 valeurs distinctes ou moins est limitée à 
l'encodage 1-of-iV. Toute colonne ayant 21 va- 
leurs distinctes ou moins est limitée aux enco- 
dages 1-of-iV et 2-of-A'^. Toute colonne ayant 
85 valeurs distinctes ou moins est limitée aux 
encodages 1-of-iV, 2-of-iV et 3-of-7V. 

2.3 Compression des index bitmaps 

Le principe de la compression par plage est le 
codage des longues plages de valeurs identiques 
par un nombre indiquant le nombre de répéti- 
tions suivi de la valeur répétée. Par exemple, 
la séquence 11110000 devient 4140. Comme il 
est fréquent que les bitmaps comprennent un 
grand nombre de zéros ou de uns sur de longues 
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Algorithm 1 Calcul du AND logique de deux 

bitmaps 

INPUT: deux bitmaps Bi et B2 

i <— itérateur sur les valeurs vraies de Bi 

j ^ itcratcur sur les valeurs vraies de B2 

S ensemble représentant les valeurs vraies de Bi A 

B2 (initialement vide) 

while i ou j n'est pas arrivé à la fin du bitmap 
do 

a <— position(i) < position(j) 
b ^ position(i) > position(7) 
while position(i) ^ position(j) do 
if (position(i) > position(j)) then 

incrcmcntcr l'itcrateur i si possible, sinon 
sortir de la boucle 
else 

incrcmcntcr l'itcrateur j si possible, sinon 
sortir de la boucle 
if position(i) = position(j) then 
ajouter position(i) à S 



plages, la compression par plage s'avère particu- 
lièrement appropriée. Cependant, il existe une 
autre raison pour laquelle cette compression est 
efficace : elle rend plus rapide l'exécution des 
opérations logiques. Considérons deux bitmaps 
Bi et B2 comportant chacun \Bi \ et | i?2 1 valeurs 
vraies. Des algorithmes simples, comme l'Algo- 
rithme 1, permettent de calculer les opérations 
B1AB2 et B1VB2 en temps 0{\Bi\ + \B2\). En 
utilisant des variantes de cet algorithme, nous 
obtenons le lemme suivant. 

Lemme 1. Étant donnés deux bitmaps Bi et 
B2 compressés par plage et comportant \Bi\ et 
\B2\ valeurs vraies, on peut calculer les opéra- 
tions logiques Bi A B2, Bi V B2, Bi © B2, Bi A 
not{B2), B\ ® not{B2) en un temps 0{\Bi\ + 
\B2\). 

Observons que le nombre de séquences de va- 
leurs vraies doit être égal (plus ou moins un) au 
nombre de séquences de valeurs fausses. 

L'inconvénient de l'Algorithme 1 est que les 
opérations logiques se font bit-par-bit alors que 
le microprocesseur opère sur des mots. Au lieu 
de manipuler chaque bit un à un, il peut-être 
plus judicieux de manipuler des mots. Nous dis- 
tinguons deux types de mots : les mots propres 
ne comportant que des bits vrais (1x11) ou des 



bits faux (0x00), et les autres, appelés mots 
impropres. Nous pouvons coder toute séquence 
de mots propres de même nature par un entier 
suivi d'un bit pour distinguer les deux types de 
mots propres (1x11 et 0x00), alors que les sé- 
quences de mots impropres peuvent être codées 
par un entier déterminant la longueur de la sé- 
quence, suivi par les mots impropres représentés 
in extenso. 

Wu et al. [25] appliquent cette idée sur l'enco- 
dage WAH, mais plutôt sur des mots de 31 bits. 
Ils représentent les séquences de mots propres 
du même type par un mot dont le premier bit 
est faux, le deuxième bit indique le type du mot 
propre (0x00 ou 1x11) et les 30 bits suivants 
sont utilisés pour stocker la longueur de la sé- 
quence. Les mots impropres de 31 bits sont sto- 
ckés in extenso, tout en mettant le premier bit 
à la valeur vraie pour indiquer qu'il s'agit d'un 
mot impropre. Dans le pire des cas, l'encodage 
WAH peut donc générer des bitmaps dont la 
taille est supérieure au bitmap non-compressé 
par un facteur de 32/31 ce qui représente une 
expansion de plus de 3%. Notre méthode de 
compression, EWAH {Enhanced Word-Aligned 
Hybrid), utilise un encodage avec des mots de 
32 bits"*^. Les mots impropres sont stockés in ex- 
tenso alors que les mots propres sont compressés 
à l'aide d'un mot-marqueur. Le mot-marqueur 
comprend trois informations : un bit est utilisé 
pour donner le type de mots propres, 16 bits 
pour stocker le nombre de mots propres du type 
donné, et les 15 bits suivants pour compter le 
nombre de mots impropres suivant la séquence 
de mots propres. L'inconvénient de notre im- 
plémentation est qu'il faut toujours débuter un 
bitmap par un mot-marqueur ; que le bitmap 
débute par une séquence de mots propres ou 
pas ^. Dans le cas extrême ori nous avons de très 
longues séquences de mots propres, le codage 
WAH peut s'avérer plus efficace parce qu'il uti- 
lise un mot tous les 2^° mots propres de 31 bits 
alors que nous utilisons un mot tous les 2^^ mots 
propres de 32 bits : ce scénario se produirait si 

^Par souci de simplicité, nous ne présentons notre mé- 
thode que pour les mots de 32 bits. 

^ Cette contrainte est purement technique. 
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nous avions plusieurs fois 32 x 2^° faits consé- 
cutifs sans qu'une valeur d'un attribut donnée 
n'est observée ^. Par ailleurs, dans la mesure 
où la table est suffisamment grande, il n'est pas 
possible pour l'encodage EWAH de générer des 
bitmaps compresses ayant une taille supérieure 
au bitmap non compressé (à 0,1% près), contrai- 
rement à l'encodage WAH. 

Avec la compression alignée sur les mots, pour 
effectuer une opération logique comme AND, il 
suffit de lire à la fois les mots propres de type 
1x11 et impropres. Le lemme suivant est démon- 
tré de manière semblable au Lemme 1. 

Lemme 2. Étant donnés deux bitmaps Bi et 
B2 compressés avec alignement sur les mots et 
comportant \Bi\ et\B2\ mots non nuls, incluant 
1x11 et tout mot impropre, on peut alors calcu- 
ler les opérations logiques Bi A B2, Bi V B2, 
Bi e B2, Bi A not{B2), Bi not{B2) en un 
temps 0{\Bi\ + \B2\). 

L'espace occupé par un bitmap B compressé 
par alignement sur les mots est dans 0(|S|) et 
0(|-B|) = 0(vrai(i3)) où vrai(B) est le nombre 
de valeurs vraies dans un index bitmap. De plus, 
lorsque les index bitmaps sont suffisamment creux, 
c'est-à-dire qu'ils comportent beaucoup plus de 
valeurs fausses que de valeurs vraies, la plupart 
des mots propres n'a que des bits faux (0x00) : le 
coût des opérations est dans 0(impropre(Si) -|- 
impropre(52)). 

3 Tri de la table de faits pour 
améliorer la compression des 
index bitmaps 

3.1 Formalisation du problème 

Si on suppose que l'on exploite la compression 
par plage, on peut aisément formaliser le pro- 
blème d'ordonnancement des rangées (ensemble 

''Pour une table comportant 100 millions faits et in- 
dexée par 20 000 bitmaps, ce phénomène pourrait ajou- 
ter, dans le pire des cas, 7 Mo à la taille de l'index encodé 
par EWAH par rapport à WAH. Comme un tel index fait 
plus de 180 Mo dans nos tests, l'effet est donc de moins 
de 4%. 



des bits assignés à un fait) dans un index bit- 
map. Si d{r, s) est le nombre de bits qui diffère 
entre les rangées r et s, il faut trouver l'ordre 
des rangées qui minimise ^(^1, rj+i). Par 
exemple, si deux faits sont représentés par les 
rangées de bits 0110 et 0011, alors la différence 
est de 2. Pinar et al. [18, Théorème 1] ont mon- 
tré qu'on peut réduire ce problème de l'ordon- 
nancement des faits au problème du voyageur, 
qui est lui-même NP-difficile. Ce qui montre 
que le problème de l'ordonnancement n'est pas 
plus difficile que le problème du voyageur. Nous 
constatons que comme d satisfait l'inégalité du 
triangle, il est possible de calculer une approxi- 
mation 1,5-optimale en un temps cubique [6] 
en utilisant des approximations au problème du 
voyageur. Les auteurs affirment par ailleurs que 
le problème est NP-difficile. L'objet du para- 
graphe qui suit est de démontrer que c'est ef- 
fectivement le cas. 

Théorème 1. Le problème de l'ordonnancement 
des rangées dans un index bitmap compressé par 
plage est NP-difficile. 

Démonstration. Le problème du chemin Hamil- 
tonien consiste à trouver un chemin qui visite 
chaque sommet exactement une fois. Ce pro- 
blème est NP-complet. Inspirés par Johnson et 
al. [9], nous réduisons le problème du chemin 
Hamiltonien au problème d'ordonnancement des 
rangées. Considérons un graphe quelconque G. 
Construisons une matrice M comme suit. Chaque 
colonne de la matrice représente un sommet et 
chaque rangée un arc. Pour chaque rangée, indi- 
quons par la valeur 1 les colonnes correspondant 
aux sommets joints par un arc donné. Toutes 
les autres composantes de la rangée sont nulles. 
Lorsque deux arcs r et s ont un sommet en com- 
mun d{r,s) = 1, sinon d{r,s) = 2. En mini- 
misant d(ri, rj+i), nous trouvons un chemin 
Hamiltonien s'il existe. □ 

Cependant, si le nombre de bitmaps L est pe- 
tit et que seul le nombre de faits est grand, on 
peut démontrer qu'une solution en temps poly- 
nomial est possible : c'est certainement vrai s'il 
n'y a qu'un seul bitmap. 
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Si on généralise l'ordonnancement des ran- 
gées au cas de la compression alignée sur les 
mots, le problème n'est pas toujours NP-difficile, 
même lorsque le nombre de bitmaps est grand. 
Par exemple, si la taille des mots est égale au 
nombre de rangées, le problème devient trivial. 
Formellement, on peut généraliser le problème 
ainsi : il faut ordonner les rangées dans un index 
bitmap en tenant compte que le stockage d'une 
séquence de mots propres de même type (0x00 
ou 1x11) coûte w bits, alors que le stockage de 
tout autre mot coûte w bits. Lorsque w est une 
petite constante, le problème est NP-difîicile. 

Théorème 2. Le problème de l'ordonnancement 
des rangées dans un index bitmap compressé 

par alignement des mots est NP-difficile si le 
nombre de bits par mot (w) est une constante. 

Dém,onstration. Considérons le cas où chaque 
rangée du bitmap est répétée un multiple de 
w. Il est donc possible d'ordonner les rangées 
de telle manière à ce que nous n'ayons que des 
mots propres (1x11 et 0x00). Il existe une so- 
lution optimale de ce type de problème. Dans 
ce cas, le problème est équivalent à un ordon- 
nancement des mots propres de des deux types 
afin de réduire leur compression par plage, un 
problème NP-difficile selon le Théorème 1. □ 

3.2 Méthodes de tri 

L'ordre lexicographique est défini sur des sé- 
quences d'éléments : une séquence ai, 02, . . . est 
plus petite qu'une autre séquence 61,62,... si 
et seulement s'il existe j tel que Oj < bj et 

= bi pour i < j. La commande Unix « sort » 
permet de trier des fichiers plats en utilisant le 
tri lexicographique. Cette opération est relati- 
vement peu coûteuse. Par exemple, sur l'ordi- 
nateur utilisé pour nos tests (voir la Section 4) , 
un fichier plat comportant 5 millions de lignes 
et plus de 120 Mo peut être trié en moins de 
10 secondes. L'instruction SQL « ORDER BY » 
permet aussi de trier les faits de manière lexi- 
cographique en spécifiant plusieurs colonnes : 
SELECT * ORDER BY tl, t2, t3. 

Pour montrer que le tri de gros fichiers n'ap- 
porte pas de surcharge élevée, considérons le 



problème où nous avons suffisamment de mé- 
moire interne pour stocker M éléments et un 
total de n éléments (n > M) à trier. Le tri en 
mémoire externe, tel mis en œuvre par la com- 
mande « sort », procède en deux étapes [26] : 

1. \n/M] blocs de M éléments sont lus, triés 
et écrits sur le disque un à un. 

2. Une partie de la mémoire (x éléments) est 
allouée pour l'écriture sur le disque, alors 
que le reste de la mémoire est utilisé pour 
lire les premiers z = [(M— x)/[n/M]J élé- 
ments de chaque blocs. Les éléments lus 
sont stockés dans un tas. Le plus petit 
élément du tas est retiré et déposé dans 
le tampon mémoire d'écriture. Cette der- 
nière opération est répétée ; dès qu'un des 
[n/M] tampons de lecture est vide, il est 
rempli à nouveau par les z prochains élé- 
ments du bloc. Dès que le tampon d'écri- 
ture est plein, il est écrit sur le disque. 

Ainsi, en théorie, avec une capacité de mémoire 
de AI éléments, on peut trier près de élé- 
ments en deux passages, sans accès aléatoire au 
disque. Un ordinateur disposant de quelques gi- 
gaoctets de mémoire devrait être à même de 
trier un ou deux téraoctets de données de cette 
manière. Si la mémoire disponible est insuffi- 
sante pour faire deux passages, des variantes de 
cet algorithme nécessitent [logj^^ n] passages. 

Il peut être judicieux de remplacer le tri d'une 
très grande table, par un tri par bloc sans fusion 
des blocs triés. On évite ainsi des lectures non- 
séquentielles sur le disque. Un tri par bloc peut 
être calculé plus rapidement et est facilement 
parallélisable. 

Dans notre implémentation des index bitmaps, 
lorsque nous assignons des bitmaps aux valeurs, 
nous le faisons par défaut en préservant l'ordre 
alphabétique des valeurs des attributs. Ainsi, 
dans un encodage 2-of-N, si le code 101000 est 
assigné à la valeur « arbre », le code 110000 
peut être assigné à la valeur « aaron » (voir 
l'Algorithme 2). De cette manière, le tri lexico- 
graphique de la table, et le tri des rangées de 
bits dans l'index bitmap, sont deux opérations 
équivalentes. 
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Algorithm 2 Allocation alphabétique des bit- 
maps aux valeurs d'attributs 

INPUT: Les valeurs d'un attribut en ordre 

alphabétique 

INPUT: k le nombre de bitmaps alloué pour 

chaque valeur 

INPUT: N le nombre de bitmaps 
a^{l,2,...,fc} 

for chaque valeur v de l'attribut do 
alloue les bitmaps ai, a2, ■ ■ ■ , k v 

i ^ k 

while Oj = L — (fe — i) et i > 1 do 
i i — 1 

ai + 1, aj+i ^ + 2, . . . 



Le tri par code de Gray [18] est défini sur 
des tableaux de bits. En traitant les séquences 
de bits comme des codes de Gray, la séquence 
ai, 02, • • ■ est inférieure à la séquence 6i, 62, • • • 
si et seulement s'il existe j tel que : 

ttj = impair(ai, 02, ... , Oj-i), 

hj 7^ Oj, fflj = hi pour i < j, où impair (04, 02, 
. . . , aj-i) vaut 1 s'il y a un nombre impair de 
valeurs unitaires dans la liste ai, 02, ... , aj-i et 

sinon. Le Tableau 3 présente un exemple. 

Remarque 1. Étant donné un ensemble conte- 
nant toutes les rangées de bits possibles sont re- 
présentées, un tri par code de Gray fait en sorte 
que la distance de Hamming entre deux ran- 
gées qui se suivent soit au plus égale à un. En 
d'autres termes, le tri par code de Gray fournit 
un ordonnancement optimal des rangées dans le 
cas où les codes de Gray possibles sont présents. 

Dans le cas oii la table ne comporte qu'une 
seule colonne et qu'on utilise l'encodage 1-of- 
N, le tri par code de Gray est alors équivalent 
au tri lexicographique. En effet, si ai = bi pour 
î < j et (ij 7^ bj, on a alors aj = 5^ = pour 

1 < j ; d'où impair(ai, 02, • . . , aj_i) = 0. De 
plus, oi, 02, . . . < 61, 62, ■ ■ • si et seulement s'il 
existe j tel que aj = 0, bj = 1, et ai = bi = 
pour i < j. 

S'il y a plusieurs colonnes et que l'on uti- 
lise l'encodage l-of-A'' pour chaque colonne, le 



tri par code de Gray est alors équivalent à un 

tri lexicographique oii l'ordre alphabétique est 
inversé une colonne sur deux. Ainsi, si le fait 
« Montréal, Voiture » précède le fait « Paris, 
Voiture », le fait « Montréal, Voiture » pré- 
cède aussi le fait « Montréal, Autobus ». Il est 
plus difficile de faire la même analyse lorsque 
l'encodage k-of-N pour k > 1 est utilisé. Ge- 
pendant, si on utilise l'encodage ki-oî-N pour 
la colonne i, il n'en reste pas moins que l'ordre 
du tri par code de Gray est inversé pour la co- 
lonne c lorsque '}2j<c % impaire par rapport 
à l'ordre qu'il aurait eu si X^j<c était paire. 

Pour éviter d'avoir à faire le moindre tri par 
code de Gray sur les rangées tout en bénéficiant 
des propriétés des codes de Gray, on peut mo- 
difier l'allocation des bitmaps. Si la colonne i 
suit l'encodage k-of-N, on peut trier par code 
de Gray les codes k-oî-N et allouer le premier 
code à la première valeur de l'attribut (en ordre 
alphabétique) et ainsi de suite. Ainsi, si on uti- 
lise un encodage 2-of-4, on allouera les codes 
dans l'ordre suivant 0011, 0110, 1100, 1010, et 
1001. Il suffit ensuite de trier la table de ma- 
nière lexicographique. Cette approche n'est ap- 
plicable que lorsque A; > 1. 

Afin de trier les rangées de bits par code de 
Gray, sans matérialiser un index bitmap non 
compressé, nous avons utilisé un arbre B sur 
disque [8]. L'arbre B a pour clés les positions 
des bits dont la valeur est vraie, et pour va- 
leur de ces clés la ligne du texte correspondant 
à un fait dans le fichier plat qui décrit la table 
de faits. Par exemple, si un fait représenté par 
les bits 100010001 dans l'index bitmap, nous 
utiliserons les entiers 0, 4, et 8 pour clés. En 
utilisant un encodage k-oî-N et des entiers de 
32 bits, une table de faits ayant d dimensions 
aura donc des clés de 4kd octets. En comparai- 
son, une table de faits nécessitant 100 000 bit- 
maps aura des clés utilisant 12 Ko si on sto- 
ckait les rangées de bits sans compression (par 
exemple, 100010001). Afin de réduire davantage 
la taille de l'arbre B, nous avons compressé les 
nœuds de l'arbre par LZ77. L'arbre B traite les 
séquences de bits comme des codes de Gray. 
Après avoir construit l'arbre, il suffit alors de 
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Tab. 3: Comparaison entre les deux méthodes 
de tri 



1 1 

1 1 

1 





1 

1 1 
1 1 
1 1 

1 1 
1 1 






1 1 

1 1 

1 1 

1 1 



1 1 
1 1 







1 
1 
1 

1 
1 



(a) lexicogra-(b) codes de 
phique Gray 



traverser ses valeurs de manière croissante. Le 

résultat est une table de faits triée. Sur de grosses 
tables, cette approche est au moins 100 fois plus 
lente que le tri lexicographique. C'est en par- 
tie à cause du processus coûteux inhérent à la 
construction des arbres B. Dans nos tests, nous 
n'appliquerons pas le tri par code de Gray sur 
nos gros fichiers de données. 

4 Mise en œuvre et résultats 
expérimentaux 

Pour des fins d'expérimentation, nous avons 
développé un moteur d'index bitmap en C++. 
Notre moteur lit un fichier plat dont les champs 
sont séparés par une virgule ou un autre carac- 
tère et génère l'index bitmap correspondant. Il 
est capable d'indexer des fichiers comprenant 
des millions de valeurs distinctes d'attributs et 
des milliards de lignes (faits). Pour assurer la 
reproduction de nos résultats, nous rendons dis- 
ponible notre logiciel^. 

L'index bitmap est stocké dans un seul fi- 
chier. L'entête du fichier comprend les méta- 
donnoos permettant d'associer les valeurs d'at- 
tribut aux bitmaps. Nous ne considérons pas le 
temps du chargement en mémoire de cet entête 
lors de la présentation la vitesse des requêtes, 
et de sa taille dans le calcul de la taille des 



*http : // code . google . com/p/lemiirbitmapindex/. 



index. L'indexation se fait en deux passages. 

Un premier passage sur le fichier de données 
permet de calculer un histogramme. Nous ne 
prenons pas en compte le temps de cette opé- 
ration lorsqu'on présente le temps de création 
des index. L'histogramme est matérialisé sur 
disque afin d'éviter ce passage lorsqu'on réin- 
dexe le fichier avec des paramètres différents. 
Le deuxième passage écrit dans le fichier d'in- 
dex des blocs de 256 Mo : l'index est donc parti- 
tionné horizontalement. Le processus d'écriture 
du fichier-index est toujours séquentiel, sans au- 
cun accès aléatoire. Chaque bloc comporte un 
entête donnant la position en octet au sein du 
bloc de chaque bitmap : l'entête a donc une 
taille de 4L octets où L désigne le nombre de 
bitmaps. Le reste du bloc est constitué des bit- 
maps compressés écrits l'un à la suite de l'autre. 
Lors des requêtes, seuls les bitmaps requis sont 
lus. Nous fixons le nombre de bits par mot à 32. 

Pour une indexation rapide lorsque le nombre 
de bitmaps est élevé, on évite d'accéder à chaque 
bitmap pour chaque rangée du fichier de don- 
nées; ce qui donnerait une complexité 0{nL). 
L'Algorithme 3 est exécuté sur chaque partition 
horizontale et fonctionne en temps 0{nkd + L) 
011 k est l'encodage choisi, n est le nombre de 
faits dans la partition, et d le nombre de dimen- 
sions ou de colonnes. Nous utilisons le fait qu'on 
puisse ajouter plusieurs mots propres de même 
type à un bitmap compressé par alignement de 
mots en un temps constant. 

Nous avons utilisé pour les tests le compila- 
teur GNU CGC version 4.0.2 sur une machine 
Apple Mac Pro, dotée de deux processeurs In- 
tel Xeon double cœurs tournant à une cadence 
de 2,66 GHz et disposant de 2GiB de mémoire 
vive. Les temps d'exécution rapportés corres- 
pondent au temps écoulé et comprennent donc 
tout le temps de calcul et le temps des entrées- 
sorties. 

4.1 Jeux de données 

Nous utilisons quatre ensembles de données : 
Census-Income [7], DBGEN [22], DBLP [13], et 
Netfiix [16]. Le fichier Census-Income est com- 
posé de 43 dimensions et de près de 200 mille 
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Algorithm 3 Algorithme de construction des 

bitmaps employé. Par souci de simplicité, on 
suppose que le nombre de rangées est un mul- 
tiple du nombre de bits dans un mot. 
Bi, . . . , Bl , L bitmaps compresses 
Bi.t <— Bi.h ^ LOi ^ pour 1 < i < L. 
c ^ 1 { compteur de rangées} 
N ^% {U champs} 
for chaque rangée de la table do 
for chaque attribut de la rangée do 

for chaque bitmap i correspondant à la va- 
leur d'attribut do 

met à vrai le (c mod w)° bit du mot uii 

if c est un multiple de w then 
for i in A/^ do 

ajoute c/w — |-B,| — 1 mots propres (0x00) 
à Bi 

ajoute le mot au bitmap Bi 
^ 

c+ 1 

for i in {1,2,. . . ,L} do 

c/w —\Bi\ — l mots propres (0x00) à B^ 



faits. DBGEN est constitué de données synthé- 
tiques alors que les trois autres ensembles sont 
des données réelles. La table de faits retenue 
pour DBGEN comprend 12 millions de faits et 
de 16 dimensions. La table de faits DBLP a été 
créée à partir du fichier XML représentant les 
centaines de milliers d'articles et de communi- 
cations répertoriés par le site DBLP^. Le fichier 
XML est converti en un fichier CSV oir chaque 
fait est une paire auteur-article. Les dimensions 
sont le type (compte- rendu, revue, etc.), le nom 
de la revue ou de la conférence, le nom de l'au- 
teur, le titre et l'année de publication. Les car- 
dinalités des dimensions sont 6, 3 574, 395 578, 
528 344 et 49, respectivement. Il y a environ 
1,5 millions de faits. La table de faits de Net- 
fiix comprend 4 dimensions MovicID, UscrID, 
Rating, Date dont les cardinalités sont respec- 
tivement 17 770, 480 189, 5, et 2 182 et un total 
de plus de 100 millions de faits. Avant le trai- 
tement des données Netflix, qui sont regroupées 
en 17 700 petits fichiers (un fichier par film). 





# de faits 


cardinalité 


taille 


Census-Income 


199 523 


43 


99.1 Mo 


DBGEN 


13 977 981 


16 


1.5Go 


DBLP 


1 372 259 


5 


156 Mo 


Netflix 


100 480 507 


4 


2.6 Go 



Tab. 4: Caractéristiques des jeux de données 
utilisés 



nous avons créé un fichier plat unique. L'ordre 
initial de tous les fichiers de données est rendu 
aléatoire avant chaque test à l'aide de la com- 
mande Unix du type « cat -n myfile.csv | sort 
-random-sort | eut -f 2- ». Il arrive que les jeux 
de données soient préalablement triés et pour 
rendre compte de l'apport du tri, il faut ef- 
fectuer une permutation aléatoire avant chaque 
test. A cause de cette permutation, certains ré- 
sultats peuvent varier légèrement d'une expé- 
rience à l'autre. Le Tableau 4 résume les princi- 
pales caractéristiques de nos fichiers de données. 

Pour nos tests, nous avons sélectionné trois 
dimensions pour chaque ensemble de données en 
prenant soin de choisir des dimensions ayant des 
cardinalités différentes. Par exemple, les dimen- 
sions utilisées pour Census-Income sont : âge 
(dl), éducation (d2), et migraUon code-change 
in m,sa (25^^ champ) (d3). Le Tableau 5 donne 
la cardinalité de chacune de ces dimensions. Par 
convention, la dimension ayant la plus faible 
cardinalité est toujours dl. Census-Income et 
DBLP ont tous les deux une dimension d3 dont 
la taille avoisine le nombre de faits (voir Ta- 
bleaux 4 et 5). Netflix a de loin les plus petites 
dimensions en comparaison avec le nom de faits. 





Census-Income 


DBGEN 


DBLP 


Netflix 


dl 


91 


7 


49 


5 


d2 


1 240 


11 


3 574 


2 182 


d3 


99 800 


400 000 


528 344 


17 770 



^http : //dblp . uni-trier . de/ 



Tab. 5: Cardinalités des dimensions choisies 
pour chaque jeu de données 

Pour d'autres expérimentations, nous avons 
utilisé des données synthétiques ayant une dis- 
tribution uniforme ou de Zipf et comportant en- 
viron 5 000 faits. Les données Zipfiennes sont 
composées de dimensions (d G {1,...,6}). Le 
paramètre de Zipf s, qui contrôle le biais des 
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données, est dans {0.5,1.0,1.5,2.0}. Les don- 
nées de distribution uniforme ont au maximum 
12 dimensions. Chaque valeur d'attribut est un 
entier choisi d'une manière uniforme et aléa- 
toire. La première dimension peut prendre ses 
valeurs parmi 100 valeurs distinctes, la deuxième 
parmi lOOr et la troisième parmi lOOr^, et ainsi 
de suite, où r ne peut prendre que les valeurs 1 
ou 2 et ne sert qu'à contrôler la variété dans le 
nombre des valeurs distinctes. Certains de ces 
jeux de distribution uniforme contiennent à la 
fois des attributs indépendants et dépendants. 

Les attributs « dépendants » sont obtenus de 
la manière suivante. 

Soit une rangée dont les valeurs des attri- 
buts ai, a2, . . . , Orf sont indépendantes. Une va- 
leur dépendante est calculée par ^aiPi, où la 
valeur de pi est égale à 1 avec une probabilité de 
0,2 et à sinon. Si = 0, nous choisissons 
uniformément une valeur dans {1, . . . , 100}. 

Après avoir généré les données de cette ma- 
nière, nous permutons aléatoirement les colonnes. 
Cela permet de s'assurer que les dimensions de 
cardinalité élevée ou petite ne se retrouvent pas 
en tête des colonnes et que les attributs dépen- 
dants et indépendants ne se retrouvent pas re- 
groupés ensemble. 

4.2 Tri par code de Gray 

Dans cette série d'expérimentations, nous com- 
parons les performances du tri par code de Gray 
avec celles du tri lexicographique sur les don- 
nées synthétiques de distribution uniforme et de 
Zipf. Rappelons que le tri peut s'appliquer aux 
faits ou lors de l'assignation des codes aux bit- 
maps de l'index. Pour chaque jeu de données, 
nous avons généré des index bitmaps en utili- 
sant un tri lexicographique (Lex) et un tri par 
code de Gray (Gray). Nous avons également uti- 
lisé un simple regroupement (Random-sort) sur 
la table de faits avec la commande Unix « sort - 
random-sort » : cette commande regroupe tous 
les faits identiques en séquences continues, mais 
n'ordonne pas les faits entre eux. Il est possible 
d'implémenter Random-sort en temps linéaire 
par rapport au nombre de faits (0(n)) alors que 
le tri lexicographique est en Çl{nlogn). Le tri 



des faits peut être combiné avec le tri des codes 

assignés aux bitmaps (voir la Section 3.2). Si les 
faits sont triés lexicographiquement, l'allocation 
peut se faire en utilisant le tri par code de Gray 
(Lex-Gray) ou le tri alphabétique (Lex-Alpha 
ou tout simplement Lex) . Si les faits sont en re- 
vanche triés par code de Gray, nous n'étudions 
que l'allocation alphabétique des codes aux bit- 
maps (Gray- Alpha ou tout simplement Gray). 
Pour rendre compte de l'amélioration apportée 
par les différentes méthodes de tri, nous avons 
aussi généré des index bitmaps pour des faits 
ordonnés aléatoirement (Random-shufHe) . Nous 
calculons ainsi les améliorations relatives en es- 
pace de stockage de chaque tri par rapport à 
Random-shufïle. 

Nous étudions en particulier les effets qu'ont 
sur l'indexation par bitmap le nombre de di- 
mensions, le biais des données et la valeur k 
de l'encodage k of A^. Nous avons aussi utilisé 
Census-Income (voir le Tableau 4) pour mesurer 
les mêmes performances sur des données réelles. 

La Figure 2a montre que le paramètre r, qui 
contrôle la variété dans le nombre de valeurs 
distinctes, semble presque ne pas avoir du tout 
d'effet sur les différents jeux de données de dis- 
tribution uniforme. Le tri lexicographique ré- 
duit d'environ de moitié la taille de l'index lors- 
qu'il n'y a qu'une dimension indépendante {d = 
1). Ce bénéfice est d'autant plus réduit que le 
nombre de dimensions augmente jusqu'à en de- 
venir négligeable. Par contre, Random-Sort semble 
totalement inefficace même lorsqu'il n'y a qu'une 
dimension indépendante. 

La Figure 3a montre, pour différentes valeurs 
de r de la distribution uniforme, l'impact que 
peut avoir le nombre de dimensions indépen- 
dantes d sur les performances relatives du tri 
par code Gray et du tri lexicographique. Nous 
notons une amélioration marginale (moins de 
1 ,5 %) de la taille de l'index lorsqu'il n'y a qu'une 
dimension indépendante. Cette amélioration di- 
minue lorsque le nombre de dimensions et la 
valeur de r augmentent. En comparant les deux 
versions du tri par code de Gray, nous consta- 
tons que le tri des codes alloués aux bitmaps en 
tant que codes de Gray surpasse légèrement le 
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FiG. 2: Performance de Random-sort et Lex comparée à Random-shuffle en fonction de d, k = 2. 
Pour les distributions uniformes, l'axe des x donne le nombre de dimensions dépendantes. Les 
données ont en effet 2, 4, . . . , 12 dimensions. 



tri par code Gray des faits. 

A partir de la Figure 2b, nous notons que 
le regroupement (Random-sort) réduit la taille 
d'un index bitmap tout aussi bien que le tri lexi- 
cographique à condition qu'il n'y ait pas plus 
d'une dimension au total. Le tri lexicographique 
améliore davantage ces performances pour les 
distributions de Zipf d'au moins deux dimen- 
sions. Cette figure montre bien que le tri lexico- 
graphique apporte un bénéfice substantiel, même 
pour un nombre de dimensions élevé, et que ce 
bénéfice croît en fonction du biais s. 

La Figure 3b montre l'effet que peut avoir le 
nombre de dimensions sur les performances du 
tri par code de Gray par rapport au tri lexico- 
graphique pour A; = 2 et différentes valeurs du 
biais s des distributions de Zipf. Nous consta- 
tons que plus la distribution est biaisée, plus 
le bénéfice apporté par le tri par code de Gray 
est grand. Dans nos données synthétiques, un 
biais plus grand correspond à un nombre de va- 
leurs d'attributs plus petit et donc, à des index 
bitmaps plus denses. Nous pensons que le code 
de Gray est plus compétitif sur des index bit- 
maps denses. Cependant, cet avantage diminue 
rapidement lorsque le nombre des dimensions 
croît. Pour une seule dimension, l'amélioration 
des performances est de 8 % ; au delà de 3 di- 
mensions, elle est en dessous de 2%. La diffé- 



rence observée entre Gray-Lex et Gray est négli- 
geable (moins de 2 % sur la Figure 3a et moins 
de 0,5 % sur la Figure 3b), sauf pour les données 
unidimensionnelles, oià Gray-Lex est 1 % moins 
bon que Gray. 

Des résultats similaires ont été observés pour 
k = 3 ou k = 4. Les valeurs de k plus grandes 
améliorent légèrement (environ 5 % pour d = 2 
et s = 2.0) les performances du tri par code de 
Gray par rapport au tri lexicographique. Ceci 
est également expliqué par le fait que le tri par 
code de Gray est plus compétitif sur des index 
bitmaps denses. 

En comparant les Figures 3a et 3b, nous no- 
tons que Gray (et donc Gray-Lex, dont la per- 
formance moyenne est presque identique à celle 
de Gray) fournit une amélioration par rapport à 
Lex. Cependant, cette amélioration décroît ra- 
pidement selon le nombre croissant des dimen- 
sions. 

Nous avons aussi utilisé trois jeux de don- 
nées pour voir quels sont les bitmaps les plus 
affectés par le tri. Pour minimiser le nombre 
de bitmaps (pour des raisons de lisibilité) , nous 
n'avons utilisé que k = 4 car peu de bitmaps 
sont produits pour cet encodage. Nous avons 
généré un fichier à distribution de Zipf compor- 
tant 8 449 faits et ayant un biais unitaire (s = 
1). Les colonnes utilisent 16, 15, 16, et 15 bit- 



12 



1.6 
1.4: 
1.2 

1 

0.8 
0.6 
0.4 
0.2 






Gray r=1.0 - 


H — 




Grayr=2.0 ■■ 


■X ■ 




Gray-Lex r=1 .0 •■■ 







Grau— 1 py r— ? Cl 


-PI 

LU 


\\ 

\\ 








!^ 





2 3 4 5 

# i/e dimensions indépendantes 

(a) Distribution uniforme 



Si 




Grays=0.5 — h- 

Grays=1.0 

Grays=2.0 ^ 

Gray-Lex s=1 .0 Q 

Gray-Lex s=2.0 



3 4 

# de dimensions 



(b) Distribution de Zipf 

FiG. 3: Performance de Gray et Lex-Gray comparée au tri lexicographique en fonction de d, A; = 2. 



maps et ont respectivement 1 382, 1 355, 1 378 
et 1 345 valeurs distinctes. Nous avons aussi 
généré un fichier à distribution uniforme com- 
portant 20 000 faits et 3 dimensions indépen- 
dantes avec des cardinalités respectives de 100, 
200 et 400, et 3 dimensions dépendantes géné- 
rées avec l'algorithme mentionné à Section 4.1. 
Les colonnes comptent, dans l'ordre, 200, 100, 
400, 526, 537 et 536 valeurs distinctes et elles 
utilisent 10, 9, 12, 13, 13 et 13 bitmaps. Fi- 
nalement, nous avons retenu deux extraits de 
Census-Income : Census-Income A décrit à la 
Section 5 et Census-Income B obtenu en rem- 
plaçant la dimension la plus dominante d3 de 
ce jeu (cardinalité de 99 800) par la dimension 
« dividends from stocks » de cardinalité plus 
faible (égale à 1 478). Les colonnes de Census- 
Incomne A utilisent 9, 15 et 41 bitmaps. Celles 
de Census-Income B utilisent 9, 15 et 16 bit- 
maps. 

Dans les Figures 4a et 4b, nous comparons 
l'effet de Gray et de Lex sur les différents bit- 
maps. Le facteur mesuré (1 — C/N) s'approche 
de 1 lorsque les bitmaps sont fortement com- 
pressés, mais vaut lorsqu'il y a peu de com- 
pression. Les bitmaps les plus « significatifs » 
de chaque dimension sont les plus à gauche. 
On constate un phénomène qui peut être sur- 
prenant : même si les bitmaps appartiennent à 
différentes dimensions, le taux de compression 
des bitmaps décroît de manière monotone pour 



les données synthétiques (Figures 4a et 4b) . On 
constate ce même phénomène pour Gray sur 
Census-Income (Figure 4d). Ce résultat suggère 
que le tri accélère les requêtes sur les premières 
colonnes davantage que sur les dernières, mais il 
accélère aussi les requêtes sur certaines valeurs 
plutôt que d'autres au sein d'une même colonne, 
selon que les bitmaps correspondants soient plus 
ou moins significatifs pour le tri. Par exemple, 
si l'allocation des bitmaps se fait de manière al- 
phabétique, une requête portant sur la valeur 
Aaron pourra être plus rapide qu'une requête 
portant sur la valeur Zébra. 

Dans les Figures 4c et 4d, nous avons comparé 
Random-Sort et Gray (Lex étant comparable 
à Gray). Alors que Gray compresse mieux que 
Random-Sort, on remarque aussi que Random- 
Sort ne favorise pas la compression des bitmaps 
les plus à gauche. Ce résultat est prévisible si 
on considère que Random-Sort ne trie pas les 
valeurs. Alors que Census-Income A et Census- 
Income B ne diffèrent que du choix de la der- 
nière colonne, Random-Sort a presque la même 
performance que Gray sur Census-Income B alors 
que sa performance est bien moindre sur Census- 
Income A. Cela s'explique par la colonne d3 uti- 
lisée dans Census-Income B qui a la valeur 
avec une probabilité de 89%. En effet, comme 
Random-Sort ne fait que regrouper les faits iden- 
tiques, il se trouve favorisé par une colonne ayant 
des valeurs relativement très fréquentes. 
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4.3 Effet de l'ordre des colonnes 

Le tri de la table de faits nécessite un or- 
donnancement des colonnes. Puisque le tri se 
fait avant la construction de l'index, seuls les 
histogrammes des valeurs par dimension sont 
connus. Deux stratégies simples s'offrent à l'ana- 
lyste : trier en premier sur les petites dimensions 
ou sur les dimensions dont la cardinalité est plus 
importante. Les deux techniques ont leurs avan- 
tages. Les dimensions de cardinalité élevée géné- 
rèrent plus de bitmaps et peuvent occuper plus 
d'espace si elles sont mal ordonnées. Dans la me- 
sure oià plusieurs de leurs valeurs sont relative- 
ment fréquentes (plus de 32 occurrences), un tri 
privilégiant une grande dimension est donc plus 
avantageux. En plaçant une dimension ayant un 
grand nombre de valeurs distinctes en premier, 
les dimensions subséquentes seront relativement 



peu triées : on trouvera peu de plages de va- 
leurs constantes. Nous pouvons tirer la conclu- 
sion suivante : si la cardinalité d'une des dimen- 
sions est beaucoup plus importante que celle des 
autres et comprend plusieurs valeurs dont l'oc- 
currence est élevée, il est alors plus judicieux de 
la mettre en tête du tri. En revanche, s'il y a 
peu de différences entre les cardinalités, il est 
peut-être plus préférable de trier d'abord à par- 
tir des dimensions de faible cardinalité afin que 
l'ensemble des colonnes puissent bénéficier du 
tri. 

La Figure 5 montre une comparaison de l'ef- 
ficacité de deux ordonnancement des colonnes. 
Pour ces tests, nous n'avons retenu que 3 co- 
lonnes pour chacune des tables. Les gains en 
compression dus au tri lexicographique sont d'au 
moins 20%, mais peuvent atteindre un facteur 
de dix dans le cas de Netflix. Nous constatons 



14 



que l'efïet de l'ordre des colonnes semble être 
moins prononcé pour l'encodage 4-of-iV que pour 
l'encodage 1-of-A^. Cela s'explique par le fait 
que le nombre de bitmaps générés par une grande 
dimension est moindre pour l'encodage A-oî-N 
que pour 1-of-iV. L'effet de l'ordonnancement 
des dimensions est relativement important. Pour 
DBGEN, il est nettement préférable de trier se- 
lon la plus grande dimension alors que pour 
DBLP, il est nettement préférable de trier selon 
la plus petite dimension. II suffit de consulter 
le Tableau 5 pour se rendre compte qu'il n'est 
pas préférable de trier selon la plus grande di- 
mension pour DBLP : clic comporte un demi- 
million de valeurs distinctes alors que la table 
de faits n'en comporte que 1,5 million de faits. 
Ce qui représente une fréquence moyenne infé- 
rieure à 3 pour chaque valeur distincte. Pour 
Netflix et Census-Income, la différence entre les 
deux ordonnancements est plus modérée (envi- 
ron 30 %) . Le Tableau 6 donne le détail de l'effet 
du tri sur les différentes dimensions selon l'ordre 
des colonnes. 

Le tri tend à créer des plages de valeurs iden- 
tiques sur les premières colonnes. Les effets bé- 
néfiques du tri sont sans doute moins apparents 
sur les dernières colonnes (voir le Tableau 6), 
à moins que celles-ci soient fortement corrélées 
avec les premières. Si le nombre de colonnes est 
élevé, les bénéfices du tri peuvent être moindres 
et voire même s'estomper. Dans le Tableau 7, 
nous avons trié des projections de Census-Income 
et DBGEN sur 10 dimensions dl . . . dlO {\dl\ < 
... < \dlO\, où \x\ désigne la cardinalité de la 
dimension x) . Les dimensions dl . . .d3 faisant 
parties de ces 10 dimensions ne correspondent 
pas à celles illustrées au Tableau 5. Nous notons 
que pour Census-Income, peu importe l'ordre 
des colonnes, l'effet du tri se fait sentir jusqu'à 
la dernière colonne. Pour DBGEN, l'effet se fait 
sentir sur toutes les colonnes si on tri d'abord 
sur la colonne ayant la plus petite cardinalité, 
alors que l'effet ne persiste que sur 5 colonnes 
lorsque l'on tri à partir de la plus grande car- 
dinalité (dlO). Dans tous les cas, l'effet du tri 
est nettement plus présent sur les premières di- 
mensions triées que sur les dernières. 



Si on compare le Tableau 6 avec le Tableau 7, 
on constate que pour Census-Income, il importe 
peu qu'on trie à partir de la colonne de plus 
faible cardinalité (dl) ou de plus forte cardina- 
lité. Cela s'explique parce que nous avons retenu 
une colonne de très forte cardinalité (99 800 va- 
leurs distinctes) par rapport au nombre total 
de faits (199 523). Pour DBGEN, l'avantage du 
tri à partir de la colonne de plus forte cardina- 
lité est moindre avec dix colonnes (Tableau 7) 
qu'avec trois colonnes (Tableau 6). Cela s'ex- 
plique par le fait que dans le premier cas, nous 
avons introduit la colonne dlO qui comporte un 
million de faits distincts contre un total de près 
de 14 millions de faits pour DBGEN alors que 
la colonne d3 dans le Tableau 6 ne comporte 
que 400 milles valeurs distinctes. 

L'ordonnancement des colonnes a un effet sur 
les performances de l'index dans le sens où un 
index de plus petite taille suite à un tri sera 
plus rapide. Si le tri favorise une colonne plu- 
tôt qu'une autre, les requêtes portant sur cette 
colonne devraient en bénéficier. 

On pourrait aussi élaborer d'autres stratégies 
plus sophistiquées en tenant pleinement compte 
des histogrammes. Par exemple, une dimension 
n'ayant que des valeurs avec une fréquence in- 
férieure à 32 ne devrait sans doute pas servir de 
base au tri. Dans le cas où nous avons beaucoup 
de colonnes et qu'on souhaite tout de même ti- 
rer profit du tri, on peut envisager des tech- 
niques comme le partionnement vertical. Ca- 
nahuate [3] établissent non pas l'ordre des co- 
lonnes, mais aussi l'ordre des bitmaps : leur ap- 
proche suppose que l'index bitmap a été préa- 
lablement matérialisé avant le tri. 

4.4 Effet du tri par bloc 

Jusqu'à présent, nous n'avons considéré que 
le tri de la totalité de la table de faits. Cette opé- 
ration peut s'avérer coûteuse pour les grandes 
tables de faits. En effet, le tri est une opération 
qui requiert un temps O(nlogn) alors que l'in- 
dexation d'une table de faits ayant un nombre 
déterminé de valeurs par colonne est une opé- 
ration en temps 0,{n) : pour n suffisamment 
grand, le tri dominera le temps de construction 
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d3d2dl 


ai 
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d3 
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24,45x10" 


19,62x10" 


3,46x10" 
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0,80x10" 


0,46x10" 


0,58x10" 


31,15x10" 


19,62x10" 


10,16x10" 
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sans tri 


dld2d3 


d3d2dl 


sans tri 


dld2d3 


d3d2dl 


dl 


0,79x10** 
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0,55x10" 


15,54x10" 
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12,47x10" 


d2 


2,62 xlO« 


42 407 


0,97x10*5 


0,19x10^ 


0,14x10» 


20,30x10** 


d3 


3,27x10^ 


1,61 xl0« 


1,61 xlO« 


0,20 xlO» 


44,52 xl0« 


0,92 xlO« 


total 


6,68x10** 


1,61x10" 


2,13x10" 


0,39x10" 


44,66x10" 


33,69x10** 



Tab. 6: Nombre de mots de 32 bits utilisés pour les différents bitmaps selon que les données aient 
été triées lexicographiquement à partir de la dimension la plus importante (d3d2dl) ou la dimension 
la plus petite (dld2d3) pour k = 1. 





caxdinalitcs 


Census-Income 

sans tri dl . . . dlO 
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dlO . . .dl 
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32 
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24 


0,75x10" 


d2 
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150 
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0,13x10^ 
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0,13x10^ 


9 


0,37x10^ 
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d5 
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10 824 
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0,27x10^ 


75 065 


0,25 xl0« 


50 


13,60 Xl06 


0,44x10» 


1,42x10» 


d7 


113 


12 199 


9 217 


12 178 


2 526 


23,69 xlO^ 


22,41 xlO» 


23,69x10» 


d8 


132 


20 028 


14 062 


19 917 


20 000 


24.00 xlO^ 


24,00x10» 


22,12x10» 


d9 


1 240 


29 223 


24 313 


28 673 


400 000 


24,84x10" 


24,84x10" 


19,14x10" 


dlO 


99 800 


0,50x10" 


0,48x10" 


0,30x10** 


984 298 


27,36x10" 


27,31x10" 


0,88x10" 


total 




1,11x10" 


0,64x10" 


0,87x10** 




0,122x10" 


0,099x10" 


0, 079 X 10" 



Tab. 7: Nombre de mots de 32 bits utilisés pour les différents bitmaps selon que les données soient 
triées lexicographiquement à partir de la dimension la plus importante (dlO. . . dl) ou la dimension 
la plus petite (dl. . . dlO) pour k = 1. 



des index. Un tri par bloc sans fusion des blocs 
peut se faire en temps 0{nlogn/ B) on B est 
le nombre de blocs. La différence entre log n et 
logn/B peut être significative. Si on considère 
n/B comme une constante qui ne dépend que 
de la mémoire disponible, alors le temps du tri 
devient une opération en temps linéaire. 

La question qui se pose est de savoir si le 
tri par bloc peut avoir des bénéfices compa- 
rables au tri complet. Pour tester cette hypo- 
thèse, nous avons retenu nos deux plus grosses 
tables (DBGEN et Netflix) et trié lexicographi- 
quement. Nous avons projeté chaque table sur 
trois dimensions de cardinalités différentes (voir 
la Section 4.1). La taille d'un bloc est obte- 
nue en divisant le nombre total de faits par le 
nombre de blocs souhaité. Cette valeur est pas- 
sée à la commande Unix « split » qui se charge 
de scinder la table de faits en plusieurs blocs, qui 



sont ensuite à leur tour triés par la commandes 
« sort ». Ces blocs ainsi triés sont finalement fu- 
sionnés en utilisant la commande Unix « cat » 
pour obtenir une table de faits triée par bloc. Le 
Tableau 8 montre que le temps du tri par bloc 
diminue lorsque le nombre de blocs augmente. 
Cela est dû au fait que lorsque le nombre de 
blocs est élevé, on a moins de données à trier 
par bloc et donc un tri plus rapide. 

Les Figures 6 et 7 montrent la variation du 
temps de création des index et leur taille en 
fonction du nombre de blocs utilisés pour trier 
la table de faits. Le temps de création des in- 
dex (pris à chaud, donc sans le temps de calcul 
de l'histogramme) et l'espace qu'ils occupent 
augmentent proportionnellement au nombre de 
blocs. Le traitement par bloc, sans fusion des 
blocs, empêche certains regroupement de va- 
leurs d'attributs. Plus il y a de blocs, moins il 
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FiG. 5: Taille de l'index selon que les données ne soit pas triées ou triées lexicographiquement à 
partir de la dimension la plus importante (d3d2dl) ou de la dimension la plus petite. 
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total 


taille 


tri 


fusion 


indexation 
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taille 


tri complet 


31 




65 


96 


39 
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558 


1 045 
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28 


2 


68 


98 


51 


360 


85 


572 


1 017 


264 


10 


24 
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70 


99 


58 


326 


87 
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986 


318 
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17 
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87 


107 


116 


230 


86 


601 


917 


806 


aucun tri 






100 


100 


119 






689 


689 


1 552 



Tab. 8: Temps du tri par bloc, le temps d'indexation et la taille des index pour k = 1 (temps en 
secondes et taille en Mo), seules trois dimensions par table sont utilisées. 



y de de regroupements possibles et par consé- 
quent moins de compression. Cela donne alors 
lieu à des index bitmaps plus volumineux. L'ef- 
fet est considérable : le fait de trier Netfiix en 
5 blocs peut doubler la taille de l'index (voir Ta- 
bleau 8) par rapport à un tri complet. Le temps 
de construction est plus élevé quand le nombre 
de blocs augmente, car on se retrouve avec plus 
de données à écrire sur disque. 

Par ailleurs, pour un nombre de blocs don- 
née, la taille des index et le temps de construc- 



tion varient inversement par rapport à la valeur 
de k utilisée pour l'encodage des bitmaps. L'ef- 
fet de k sur la taille et le temps vient du fait 
que lorsque k a une petite valeur, le nombre 
de bitmaps est plus élevé. Un index plus pe- 
tit est construit plus rapidement. Cependant, 
parce que des bitmaps moins nombreux, mais 
plus sont moins compressibles, la taille de l'in- 
dex n'est pas proportionnelle au nombre de bit- 
maps. En effet, alors que le nombre de bitmaps 
décroît exponentiellement avec k, la taille de 
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l'index n'est réduite que d'un facteur de 2 à 4 
lorsque k passe de 1 à 4. 

Nous présentons le temps d'interrogation des 
données via les index bitmaps en fonction du 
nombre de blocs utilisés pour le tri. Pour cela, 
nous avons sélectionné pour chaque jeu de don- 
nées 12 requêtes d'égalité ayant des sélectivités 
différentes. Chaque requête est définie sur une 
seule dimension dont la cardinalité est élevée. 

Nous constatons à partir de la Figure 8 que le 
temps d'interrogation augmente en fonction du 
nombre de blocs, pour devenir presque constant 
pour les plus grandes valeurs du nombre de blocs. 
De plus, pour un nombre de blocs donné, le 
temps d'interrogation est inversement propor- 
tionnel à la valeur de k utilisée pour l'encodage 
des bitmaps. En effet, lorsque la valeur de k 
est grande, on consulte plus de bitmaps {k bit- 
maps) pour chaque dimension. Le fait de passer 
dek = lkk = 2 multiplie le temps de traite- 
ment par un facteur de 6 ou plus, même si le 
nombre de bitmaps consulté n'est que doublé. 
Il y a donc un compromis à faire entre le temps 
de construction et l'espace occupé par l'index 
d'une part, et la performance de l'index d'autre 
part. 

Au total, il semble que le remplacement du 
tri complet par un tri par bloc ne soit pas une 
bonne stratégie pour des tables de faits ayant 
moins que des centaines de millions de faits. En 
effet, le Tableau 8 montre que si le tri par bloc 
peut être 20 % plus rapide, il peut aussi générer 
des index plus volumineux qui prennent plus de 
temps de construction. En fait, le tri par bloc 
peut même causer une augmentation du temps 
total d'indexation. Les performances des index 
résultant d'un tri par bloc sont moindres selon 
la Figure 8. 

5 Conclusion et perspectives 

Nous avons utilisé le tri de la table de faits 
pour réduire la taille des index bitmaps. A l'aide 
du tri, nous pouvons réduire par un facteur de 
deux la taille d'un index, tout en doublant par- 
fois la performance de l'index. Dans les cas où 
il y a un grand nombre de colonnes, ces gains se 



concentrent surtout sur les premières colonnes. 

Les techniques de tri et d'allocation des bit- 
maps que nous avons considérées n'exploitent 
pas l'histogramme des données. Nous travaillons 
à améliorer l'effet du tri en tenant compte de 
la distribution de la fréquence des valeurs d'at- 
tributs. Selon nos tests préliminaires, certains 
gains supplémentaires sont possibles. 

Notre table de faits la plus grande comportait 
100 millions de lignes. Pour les tables beaucoup 
plus grandes, ayant des milliards ou des billions 
de faits, un tri complet de la table peut s'avérer 
beaucoup plus coûteux que le temps de création 
de l'index. En effet, l'indexation se fait en temps 
linéaire par rapport au nombre de fait (0(n)) 
alors que le tri requière un temps 0{n log n) . Les 
solutions alternatives comme le tri par bloc sans 
fusion ou le simple regroupement des valeurs si- 
milaires pourraient s'avérer alors plus intéres- 
santes. Nous prévoyons de traiter ces cas dans 
nos futurs travaux. 
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